Initial Product Offering System and Method

ABSTRACT

A system and method for making an initial product offering of tangible products and services. A price for a product may be determined by calculating an aggregate customer history factor by aggregating customer history factors of potential purchasers in a buying group, calculating a cumulative demand for a product as a function of (i) expected purchase quantities of the product indicated by the potential purchasers in the buying group and (ii) the aggregate customer history factor, and setting a price of the product as a function of the cumulative demand for the buying group. The tangible products and services may be offered at the determined price.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of, and therefore claims priority to,prior U.S. patent application Ser. No. 11/515,113 filed on Sep. 1, 2006,which is a continuation-in-part of prior U.S. patent application Ser.No. 09/649,224 filed on Aug. 25, 2000, now U.S. Pat. No. 7,103,565 whichclaims benefit of prior U.S. Provisional Patent Application No.60/150,993, filed on Aug. 27, 1999. The entire contents of these priorapplications are incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates generally to digital commerce and specifically tothe pricing and sale of products and services through a network basedproduct offering using demand packets.

2. Description of Related Art

Individual buyers of both consumer and business related products andservices (identified hereinafter as “singular customer”) are at adisadvantage when making purchases because there is little negotiatingleverage for a single sale. Large volume purchasers, on the other hand,have substantial leverage, such as when a retailer purchases goods froma wholesale supplier. There is a continuing need for a purchasing systemthat provides the leverage of large volume purchasing interest tosingular customers, while disintermediating the sales chain of theproduct.

One approach to providing a solution for volume and pre-determinedpricing curve based system for the aggregation of purchasing interest isoutlined in U.S. Pat. No. 6,047,266 entitled “Demand Aggregation throughOnline Buying Groups.” This patent describes a method wherein an onlinebuying group, referred to as a “co-op” is formed for the specificpurpose of purchasing a particular product based on a predeterminedpricing curve that is modified by the market data from the co-op.However, as significant disadvantages, (i) the seller has to disclose tothe demand aggregation system its pricing curve which may be tradesecret information instead of dynamically providing the pricing for theproduct, (ii) the system targets the co-op information to “a” particularvendor or manufacturer of the product, (iii) the system does not provideexisting market-wide price transparency, and (iv) the system does notallow potential buyers to create their own said co-ops as the co-opstend to be driven by the system and effectively by the pricing curveinformation provided by the vendor or the manufacturer.

Another approach to effectuating bilateral buyer-driven commerce throughallowing prospective buyers to communicate a binding purchase offerglobally to potential sellers, for sellers to conveniently search forpotential buyer purchase offers, and for sellers to bind a buyer to itsoffer is outlined in U.S. Pat. No. 5,794,207, entitled “Method andApparatus for a Cryptographically Assisted Commercial Network SystemDesigned to Facilitate Buyer-Driven Conditional Purchase Offers.” Thispatent describes a method and system whereby buyers can negotiate apurchase price of a product or service with a seller through an onlinebid-offer system. However, as a significant disadvantage, the patentdoes not create buying groups that have the ability of large volumediscounts.

There remains the need for a digital commerce system that allowssingular customers to create their own demand or purchasing interestpools, and routes these packets of demand (“demand packets”) to aplurality of hosts comprising (i) multiple suppliers, vendors,manufacturers and distributors of the particular product or service,(ii) auction networks where these demand packets may represent both selland buy-side entries, (iii) vertical exchanges where similar category ofproducts and services are sold and brokered, and (iv) horizontalmarketplaces where similar categories of products and services are soldand brokered. There also remains the need for this system to beavailable over a plurality of network access devices comprising mobilephones, mobile computers, personal computers, laptop computers, handheldcomputers, personal digital assistants, and handheld computers. Thesystem should further provide optimal pricing for the products coupledwith market-wide price transparency.

SUMMARY OF THE INVENTION

To overcome the problems of conventional demand and supply aggregationsystems, the principles of the present invention provide for a methodand for determining a price for a product. The method may includecalculating an aggregate customer history factor by aggregating customerhistory factors of potential purchasers in a buying group. The customerhistory factors may include at least one of the following customerrelated parameters: customer rating parameter, customer transactionparameter, customer demographics parameter, customer geographicsparameter, customer psychographic parameter, and customer behavioralparameter. The method further calculates a cumulative demand for aproduct as a function of (i) expected purchase quantities of the productindicated by the potential purchasers in the buying group and (ii) theaggregate customer history factor. A price of the product may be set asa function of the cumulative demand for the buying group.

The system and method of the invention will be more readily understoodand apparent from the following detailed description of the inventionwhen read in conjunction with the accompanying drawings, and from theclaims, which are appended at the end of the detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing will be appreciated more fully from the following furtherdescription thereof, with reference to the accompanying drawings,wherein:

FIG. 1 is an abstract diagram of a system for group buying according tothe invention;

FIG. 2 illustrates records in a product database;

FIG. 3 illustrates records in a conditions of indications of interestdatabase;

FIG. 4 illustrates records in a demand packet database;

FIG. 5 illustrates records in a product pricing database;

FIG. 6 illustrates records in a customer sales database;

FIG. 7 illustrates records in a product network database;

FIG. 8 shows the description of the demand packet;

FIG. 9 is a block diagram of a network system server;

FIG. 10 is a block diagram of a demand packet server;

FIG. 11 is a block diagram of a transaction server;

FIGS. 12A-12B are a flow chart of a customer process in the productoffering for group buying according to the invention;

FIGS. 13A-13E are a flow chart of a system process in the productoffering for group buying according to the invention;

FIG. 14 is a block diagram of an exemplary system 1400 for determining acustomer history factor from various input variables or parameters; and

FIG. 15 is a block diagram of an exemplary neural network diagram thatmay be used to predict whether a potential buyer will become an actualbuyer after submitting an indication of interest based on customer andeconomic related variables.

DETAILED DESCRIPTION

To provide an overall understanding of the invention, certainillustrative embodiments will now be described, including demand packetsand a system and method for group buying using same demand packets.However, it will be understood by those of ordinary skill in the artthat the demand packet may be adapted to other forms, physical andvirtual, provided they are capable of including the necessary demandpacket parameters described below. It will also be understood that themethods and systems described herein can be suitably adapted to anyother sales model where a customer can make an indication of interestwhile reconfirming based on trigger events, such as, for example,reconfirm automatically if the price of the product is in the givenrange. The terms “product” and “item” are used interchangeably herein todenote products of all kinds comprising products, services, consumerproducts, and solutions in all physical and abstract forms. The terms“customer”, “purchaser”, and “operator” are used interchangeably hereinto denote a potential buyer, which places an indication of interest topurchase the given product.

Overview of System

FIG. 1 shows a preferred embodiment of a system 100 in accordance withthe present invention, where a mobile computer user 105, wireless deviceuser 110, personal computer user 115, personal computer user 120, laptopcomputer user 125, handheld device user 130, and personal digitalassistant user 135 (collectively, the “User”) through a network 140 suchas the Internet connects to a network system server 145, which is indirect communications with a demand packet server 150. The demand packetserver 150 is further in direct communications with a transaction server155 comprising four servers: a supplier server 160, an auction server165, a vertical exchange server 170, and a horizontal marketplace server175. The supplier server 160 is further in direct communications with aplurality of suppliers for the product comprising manufacturers 180 anddistributors 182. The auction server 165 is further in directcommunications with a plurality of auction venues, where the demandpacket may be auctioned, comprising auction site #1 184 and auction site#N 186. The vertical exchange server 170 is further in directcommunications with a plurality of vertical exchanges for the productcomprising vertical exchange #1 188 and vertical exchange #N 190. Thehorizontal marketplace server 170 is further in direct communicationswith a plurality of horizontal marketplaces for the product comprisinghorizontal marketplace #1 192 and horizontal marketplace #N 194.Generally, the configuration of the system 100 allows the network systemserver 145 to present the User with product information on a specificproduct offering in a computer searchable form and the ability for theUser to create a new product offering through the system.

As will be discussed in more detail below, the User can select a productoffering through the network system server 145 and place an indicationof interest. The network system server 145 collects additionalindications of interest in the same product offering whilepre-determined conditions are fulfilled (e.g., time frame for theproduct offering). After suspension of the collections of theindications of interest for the product offering, the network systemserver 145 transmits the indications of interest to the demand packetserver 150. The demand packet server 150 processes the receivedinformation and communicates with the transaction server 155. Based onthe indications of interest transmitted by the demand packet server 150in the form of demand packets and certain pre-determined conditions ofthe product offering, the transaction server 155 presents to the Uservia the demand packet server 150 and the network system server 145,offers from one or more product fulfillment destinations for thespecific product offering.

In the communicating relationship, the network system server 145collects reconfirmation at the offer price for all the Users that hadpreviously placed an indication of interest in the specific productoffering. Upon receiving the reconfirmations, the system 100 negotiatesthe offer price with the plurality of fulfillment destinations that hadpresented the offer, selects the final offer price, the transactionserver 155 reaffirms the offer price and notifies the User via thedemand packet server 150 and the network system server 145, regardingparameters for consummating the purchase transaction (e.g., physicalshipping of the product, electronic delivery of the service).

Software Databases

A product database 200 stores product parameters for a plurality ofproduct offerings. As shown in FIG. 2, the product database 200 stores aplurality of records 250, each record including a plurality of fields,the plurality of fields comprising: a product identifier 205 uniquelyidentifying the product in the product offering, the vendor name 210identifying the manufacturer of the product, the product name 215identifying the name of the product, the product description 220identifying the description of the product, the release date 225identifying the date on which the product will be released into themarket, the available date 230 identifying the date on which the productwill be available through the system 100, the MSRP 235 identifying themanufacturer's retail price for the product, the pricing range max 240identifying the maximum price of the product for the product offering,and the pricing range min 245 identifying the minimum price of theproduct for the product offering. For example, referring to record 255,the product 101, which is an automobile is manufactured by Ford andtermed Toy 2000. Furthermore, this record 255 indicates that the releasedate of the product is December 1999 and its available date on thesystem 100 is December 1999 as well. The manufacturers retail price forthe product is $20,000, its maximum range is $20,000 and its minimumpricing range is $14,000.

A conditions of indications of interest database 300 stores theconditions upon which the product offering shall be conducted for theproduct. As shown in FIG. 3, the conditions of indications of interestdatabase 300 stores a plurality of records 330, each record including aplurality of fields, the plurality of fields comprising: a productidentifier 205 uniquely identifying the product in the product offering,the conditions of indications of interest 305 comprising: the pricingdate 310 identifying the date on which the product offering will bepriced, the min # indications 315 identifying the minimum number ofindications of interest that will be received to conduct the productoffering, and other conditions 320 and 325 as may be deemed appropriateby the creator of the product offering. For example. referring to record335, the product 101 will be priced on Dec. 1, 1999 if at least 10indications of interest to purchase the product are received by thesystem 100.

A demand packet database 400 stores the parameters that form a demandpacket for each product offering. As shown in FIG. 4, the demand-packetdatabase 400 stores a plurality of records 415, each record including aplurality of fields, the plurality of fields comprising: a demand-packetidentifier 405 uniquely identifying the demand packet, the demand packetdestination identifier 705 uniquely identifying the pre-determinedfulfillment destinations where the demand packet is to be routed, theproduct identifier 205 identifying the product for which the demandpacket has been created, the customer identifier 605 identifying thecustomer indicating the demand for the given demand packet, theindication date 615 identifying the date on which the demand wasindicated by the customer into the demand packet database, the quantity620 identifying the number of items of the product which are sought, thecumulative demand size 410 identifying the cumulative size of thedemand, the customer history factor 635 identifying the average purchaserate of the customer, and the pricing date 310 identifying the date onwhich the product offering will be priced. For example, referring torecord 420, the demand packet A2004 has a demand destination of DD20 andthe packet is being created for a product 123 where an indication ofinterest is placed on Apr. 15, 2000 by customer C002 with a customerhistory factor of 68% for a quantity of 2 items. At this record 420, thecumulative demand size for the product offering is 2 and the offeringwill be priced on Jun. 22, 2000.

A product pricing database 500 stores, for each product offering, thepricing date along with the final offer from the fulfillment destinationon the pricing date. As shown in FIG. 5, the product pricing database500 stores a plurality of records 510, each record including a pluralityof fields, the plurality of fields comprising: a product identifier 205uniquely identifying the product in the product offering, the releasedate 225 identifying the date on which the product will be released intothe market, the available date 230 identifying the date on which theproduct will be available through the system 100, the MSRP 235identifying the manufacturer's retail price for the product, the vendorprice 505 identifying the final offer price from the fulfillmentdestination that is selected in conjunction with fulfilling the purchasetransaction for the product offering, and the pricing date 310identifying the date on which the product offering will be priced. Forexample, referring to record 515, the product 101 will be priced on Dec.28, 1999 at a vendor price of $16,000.

A customer sales database 600 stores, for each customer, the details ofinteraction with the system 100 for specific product offerings. As shownin FIG. 6, the customer sales database 600 stores a plurality of records655, each record including a plurality of fields, the plurality offields comprising: a customer identifier uniquely identifying thecustomer, the customer name, the product identifier 205 uniquelyidentifying the product in the product offering, the date of indication615 identifying the date on which the customer placed the indication ofinterest for the product offering, the quantity 620 identifying thenumber of items the indication of interest is being placed for, the dateof reconfirmation 625 identifying the date on which the customerreconfirmed its indication of interest, the shipping info 630identifying the address the product is being shipped, the billing info635 identifying the method of payment for the product, the customerhistory factor identifying the average purchase rate of the customer forpast product offerings, the date shipped 645 identifying the date onwhich the product was shipped to the customer, and the comments 650 oninteractions with the customer. For example, referring to record 660,the customer c001 identified as Joe Schmoe placed an indication ofinterest of 2 items for product 101 on Nov. 28, 1999 and reconfirmed theindication of interest on Dec. 28, 1999. Referring further to record660, the customer c001 asked for the product to be sent to 11 WalkerDrive, New York, N.Y. 10000, provided a credit card # as his preferredmethod of payment where the product was shipped on Jan. 7, 2000.Referring further to record 660, the customer c001 has a customerhistory factor of 54%, and there have been interactions with thecustomer.

A product network database 700 stores, for each product, the network ofpreferred and pre-determined fulfillment destinations for specificproduct offerings. As shown in FIG. 7, the product network database 700stores a plurality of records 730, each record including a plurality offields, the plurality of fields comprising: a product identifier 205uniquely identifying the product in the product offering, the vendorname 210, the product name 215, the demand destination identifier 705uniquely identifying the preferred and pre-determined fulfillmentdestinations for the product in the product offering, the supplier table710 that stores a plurality of records 755, each record including aplurality of fields, the plurality of fields comprising: S102 735identifying the electronic addresses of the preferred and pre-determinedfulfillment destinations in the supplier category, the auction table 715that stores a plurality of records 755, each record including aplurality of fields, the plurality of fields comprising: A102 740identifying the electronic addresses of the preferred and pre-determinedfulfillment destinations in the auction category, the vertical exchangetable 720 that stores a plurality of records 755, each record includinga plurality of fields, the plurality of fields comprising: V102 745identifying the electronic addresses of the preferred and pre-determinedfulfillment destinations in the vertical exchange category, and thehorizontal marketplace table 725 that stores a plurality of records 755,each record including a plurality of fields, the plurality of fieldscomprising: H102 735 identifying the electronic addresses of thepreferred and pre-determined fulfillment destinations in the horizontalmarketplace category. For example, referring to record 760, for product101 with the name Toy 2000 to be supplied by Ford, the demanddestination identifier is DD01 which is sent to pre-determinedfulfillment destinations S102 for the supplier category, A102 for theauction category, V102 for the vertical exchange category, and H102 forthe horizontal marketplace category.

The Demand Packet

FIG. 8 shows a preferred embodiment of the demand packet 800, which iscreated by the demand packet server 150 from the network basedaggregated information collected by the network system server 145. Thedemand packet 800 is utilized by the demand packet server 150 tocommunicate with the transaction server 155 and its sub servers in orderto consummate the purchase transaction. Each demand packet 800 stores aplurality of relevant records comprising: the demand packet identifier405, the demand destination identifier 705, the product identifier 102,the pricing date 310, the demand size 805 uniquely identifying thecumulative size of the demand collected through all the indications ofinterest times the quantity 620 in the demand packet database 400, thecustomer history factor 810 identifying the average purchase rate of allthe customers that placed indications of interest for the productoffering, the expected demand 815 identifying the multiplication of thedemand size 805, and the customer history factor 810, the vendor name210, the product description 215, the product MSRP 235, the productpricing max 240, the product pricing min 245, the product vendor price505, and the conditions of indication of interest 305 based upon whichthe potential customers had placed their indication of interest furthercomprising: the pricing date 310, the min # indications 315, thecondition 3 320, and the condition 4 325.

Hardware Servers

FIG. 9 is a block diagram of a network system server 145. The networksystem server 145 includes a processor 920, and connected thereto, arandom access memory 910, a read-only memory 905, a network card 915, asystem clock 930, and a storage device 935. The network card 915 can beany network card capable of handling numerous logical connections 925 toa network 945, as required by the number of customers, fulfillmentdestinations, financial transaction processors, and logical connections950 to the demand packet server requiring resources from the networksystem server 145. The storage device 935 can be any storage devicecapable of maintaining a product database 200, a customer sales database600, and financial and credit processor 940, such as a hard drive,storage area network, redundant array of inexpensive disks, or othermass storage device. If the databases 200, 600 on the storage device 935are particularly large, a separate transaction processor may be providedto off-load database management from the processor 920. The processor920 and memories 910, 905 may be any processor and memories known in theart that are consistent with the volume of traffic handled by thenetwork card 915, including any associated security protocols, and thevolume of data stored in the storage device 935. Suitable networkservers are manufactured by Compaq Computers, Dell, IBM, and SunMicroSystems. Such servers may employ a processor with multiple centralprocessing units, and will operate under control of an operating systemsuch as Unix, Linux, other Unix variants, DOS, Windows or its variants,VMS, and Solaris. The network system server 145 will also run additionalprograms or software modules from the operating system to control serveroperations, web server operations, authentication functions, networksecurity, and database management, many alternatives for which are knownin the art and commercially available. The invention may be usefullypracticed with any of these computers, operating systems, and otherprograms. The software modules will also provide and operate a web siteprovided by the network system server 145 for the customers, accordingto information stored on the storage device 935.

FIG. 10 is a block diagram of a demand packet server 150. The demandpacket server 150 includes a processor 1020, and connected thereto, arandom access memory 1010, a read-only memory 1005, a network card 1015,a system clock 1025, and a storage device 1045. The network card 1015can be any network card capable of handling numerous logical connections1035 to a network 1055, as required by the number of customers,fulfillment destinations, demand packet processors, logical connections1030 to the network system server 145, and logical connections 1040 tothe transaction server 155 requiring resources from the demand packetserver 150. The storage device 1045 can be any storage device capable ofmaintaining a product pricing database 500, a conditions of indicationsof interest database 300, a demand packet database 400, and a demandpacket processor 1050, such as a hard drive, storage area network,redundant array of inexpensive disks, or other mass storage device. Ifthe databases 300, 400, 500 on the storage device 1045 are particularlylarge, a separate transaction processor may be provided to off-loaddatabase management from the processor 1020. The processor 1020 andmemories 1010, 1005 may be any processor and memories known in the artthat are consistent with the volume of traffic handled by the networkcard 1015, including any associated security protocols, and the volumeof data stored in the storage device 1045. Suitable network servers aremanufactured by Compaq Computers, Dell, IBM, and Sun MicroSystems. Suchservers may employ a processor with multiple central processing units,and will operate under control of an operating system such as Unix,Linux, other Unix variants, DOS, Windows or its variants, VMS, andSolaris. The demand packet server 150 will also run additional programsor software modules from the operating system to control serveroperations, web server operations, authentication functions, networksecurity, demand packet processing and database management, manyalternatives for which are known in the art and commercially available.The invention may be usefully practiced with any of these computers,operating systems, and other programs.

FIG. 11 is a block diagram of a transaction server 155. The transactionserver 155 includes a processor 1120, and connected thereto, a randomaccess memory 1110, a read-only memory 1105, a network card 1115, asystem clock 1125, and a storage device 1145. The network card 1115 canbe any network card capable of handling numerous logical connections1130 to a network 1175, as required by the number of customers,fulfillment destinations, and transaction processors 1155, 1160, 1165,1170, logical connections 1135 to the network system server 145, andlogical connections 1140 to the demand packet server 150 requiringresources from the transaction server 155. The storage device 1145 canbe any storage device capable of maintaining a product network database700, a supplier processor/server 1155, an auction processor/server 1160,a vertical exchange processor/server 1165, and a horizontal marketplaceprocessor/server 1170, such as a hard drive, storage area network,redundant array of inexpensive disks, or other mass storage device. Ifthe database 700 on the storage device 1145 are particularly large, aseparate transaction processor may be provided to off-load databasemanagement from the processor 1120. The processor 1120 and memories1110, 1105 may be any processor and memories known in the art that areconsistent with the volume of traffic handled by the network card 1115,including any associated security protocols, and the volume of datastored in the storage device 1145. Suitable network servers aremanufactured by Compaq Computers, Dell, IBM, and Sun MicroSystems. Suchservers may employ a processor with multiple central processing units,and will operate under control of an operating system such as Unix,Linux, other Unix variants, DOS, Windows or its variants, VMS, andSolaris. The transaction server 155 will also run additional programs orsoftware modules from the operating system to control server operations,web server operations, authentication functions, network security,fulfillment processing, and database management, many alternatives forwhich are known in the art and commercially available. The invention maybe usefully practiced with any of these computers, operating systems,and other programs.

Method of Operation

An embodiment of the process for the system 100 described above will nowbe described in detail by reference to FIGS. 12A-12B and FIGS. 13A-13E.

Customer Process

FIGS. 12A-12B are flow charts showing a customer's interaction process1200 with the system 100 for group buying according to the invention,which also shows the resources used for each step. The customer process1200 begins when the customer logs on to a secure web site 1205 that isprovided by the network system server 145. Once the customer is loggedon to the system 1205, the customer interactively browses lists ofavailable product categories 1210, each product category identifying anoffering for that product from the associated product database 200, forproduct offerings that may be of interest to the customer. The network,system server 145 maintains communication with the product database 200,which is periodically updated to add and remove product offerings. Allweb server communications are secure, such as through the secure socketlayer (SSL) communications through digital encryption identificationsthrough commercially available services such as Verisign. After thecustomer has had a chance to view the product categories and select adesired product 1210, the customer is asked if there is an interest inplacing a conditional indication of interest in purchasing the productas part of an offering group 1215. This entails two options 1215: (1) nointerest in placing an indication of interest wherein the customer hasan option to create their own product offering for a specific product1220 and then view product categories to select the product 1210, orview product categories once again to select a desired product 1210, and(2) place indication of interest for the desired product 1225 which isentered into the secure demand packet database 400, and, if the offeringis still open, the customer receives e-mail confirmation of the acceptedindication of interest. Indications of interest to purchase an item areaggregated into a group, along with available information aboutcustomers, such as their histories of purchasing through the demandpacket server. This group information is then used to negotiate a grouppurchase price with potential fulfillment destinations. The negotiationmay occur through human interaction between the web provider and thefulfillment destinations, or may occur using a pre-determined protocolbetween the web server and a remote server operated by the fulfillmentdestinations. During the entire negotiation process, the customer waitsfor receiving the offer from one fulfillment destination or multipleoffers from a plurality of fulfillment destinations 1230. Once a priceis negotiated, each customer who indicated an interest to purchasereceives an e-mail detailing the offer 1230. The offer is sent to thecustomer in accordance with the offer entry in the product pricingdatabase 500. At this point, the customer may accept the offer andproceed with a purchase transaction, or the customer may reject theoffer. If the customer chooses to accept the offer(s), the customer isrequired to reconfirm the offer(s) within a specified amount of time asindicated in the customer's offer e-mail 1235. The reconfirmationprocess 1235 is conducted in accordance with information exchangebetween the network system server 145, the demand packet server 150, andthe demand packet database 400. Where an offer is rejected by one ormore customers, this information may optionally be stored and used toattempt another round of price negotiation. After the specified timeframe, the reconfirmations are updated in the demand packet database 400for the entire group that had previously placed an indication ofinterest. The reconfirmations may be of multiple nature meaning that onecustomer may reconfirm for multiple offers that he may have receivedfrom a plurality of fulfillment destinations. The aggregatereconfirmation group information is re-presented to the fulfillmentdestinations that had provided the offer, and the final offer price fromone or more fulfillment destinations is provided to the customers 1240.At this point, if the customer desires credit processing 1245, thecustomer is required to enter credit processing information 1250 that isexchanged with a credit processor 940 for the purposes of providing acredit solution to the customer. In the following step, the customer isrequired to enter product delivery information such as the shippinginformation 1260 which is updated into the customer sales database 600which marks the completion of the purchase transaction 1265 on thesystem 100.

FIGS. 13A-13E are flow charts showing a system process 1300 for groupbuying according to the invention, which also shows the resources usedfor each step. The system process 1300 begins when a user, comprising acustomer or one of the plurality of fulfillment providers, logs on thesystem. If the user is one of the plurality of fulfillment providers,the web site offers two options: (1) to view an existing demand packet,as will be discussed later, and (2) create a new product offering. Tocreate a new product offering. the fulfillment destination selectsproducts 1305 and provides product specific information 1310 including amanufacturer suggested retail price (MSRP), a range of offering prices,conditions for the offering, and a time period for the offer. Once aninterested user has provided the required information, a product listingmay be added 1315 to the product database 200, and the conditions ofindication of interest to be added to the conditions of indication ofinterest database 300. The system 100 then interacts with customers andcollects the indications of interest 1320 as described above until anyconditions of indication of interest set forth by the fulfillmentdestination have been satisfied 1325. In step 1320, the system 100exchanges the customer specific information with the demand packetdatabase 400. In step 1325, the system 100 exchanges the indication ofinterest information with the conditions of indication of interestdatabase 300. If the fulfillment destination's conditions have not beensatisfied by the pricing date, the fulfillment destination may changethe conditions. At this point, the system 100, in accordance with thedemand packet database 400, creates a demand packet 1330.

Depending on the preferred and pre-determined fulfillment destinationsfor the demand packet, the demand packet may be routed to one or more offulfillment processes including: a supplier process for a plurality ofsupplier destinations 1335, an auction process for a plurality ofauction destinations 1340, a vertical exchange process for a pluralityof vertical exchange destinations 1345, and a horizontal marketplaceprocess for a plurality of horizontal marketplace destinations 1350.

In the supplier process 1335, the supplier server 1155 receives thedemand packet 1335.05 and routes the demand packet to a plurality ofsupplier category fulfillment destinations 1335.10 prior to which thesupplier server 1155 secures routing information from the productnetwork database 700 and vice versa. Based on the information containedin the demand packet and the aggregated indications of interest obtainedthrough the demand packet database 400, one or more supplier categoryfulfillment destinations announce the offers which includes the pricing1335.15. The offers are entered into a product pricing database 500, andthe pricing information is e-mailed to participating customers forreconfirmation 1335.20. In a finite time frame, the system 100 collectsreconfirmations from the customers that had placed an indication ofinterest 1335.25, and this information is provided for in the demandpacket database 400 and the customer sales database 600. It should benoted that one customer may, for one previously entered indication ofinterest, submit multiple reconfirmations to one or more of the offersreceived from the system 100. Upon transmitting the reconfirmations toall the supplier category fulfillment destinations that had made anoffer based on the demand packet, the pricing is confirmed by the system100, and, following that, the system 100 negotiates the best price withone or more supplier category fulfillment destinations. This set offinal offers is compared against offers received from the auctionprocess 1340, a vertical exchange process 1345, and a horizontalmarketplace process 1350 to determine the final best price offer1335.30, which if accepted by the system 100, will prompt the customersfor entering credit information 1335.35 and, if required 1335.40,connect the customers to a credit processor 940 for credit solutions. Asshown in step 1335.45, the system collects final shipping informationand payment from the customer and stores it into the customer salesdatabase 600. After shipping and payment information acquisition, thesystem 100 completes the purchase transaction and confirms via e-mailthe closing of the purchase transaction with the customers 1335.50.

In the auction process 1340, the auction server 1160 receives the demandpacket 1340.05 and routes the demand packet to a plurality of auctioncategory fulfillment destinations 1340.10 prior to which the auctionserver 1160 secures routing information from the product networkdatabase 700 and vice versa. Based on the information contained in thedemand packet and the aggregated indications of interest obtainedthrough the demand packet database 400, one or more auction categoryfulfillment destinations announce the offers which includes the pricing1340.15. The offers are entered into a product pricing database 500, andthe pricing information is e-mailed to participating customers forreconfirmation 1340.20. In a finite time frame, the system 100 collectsreconfirmations from the customers that had placed an indication ofinterest 1340.25, and this information is provided for in the demandpacket database 400 and the customer sales database 600. It be notedthat one customer may for one previously entered indication of interestsubmit multiple reconfirmations to one or more of the offers receivedfrom the system 100. Upon transmitting the reconfirmations to all theauction category fulfillment destinations that had made an offer basedon the demand packet, the pricing is confirmed by the system 100, andfollowing that the system 100 negotiates the best price with one or moreauction category fulfillment destinations. This set of final offers arecompared against offers received from the supplier process 1335, avertical exchange process 1345, and a horizontal marketplace process1350 to determine the final best price offer 1340.30, which, if acceptedby the system 100, will prompt the customers for entering creditinformation 1340.35 and, if required, 1340.40 connect the customers to acredit processor 940 for credit solutions. As shown in step 1340.45, thesystem collects final shipping information and payment from the customerand stores it into the customer sales database 600. After shipping andpayment information acquisition, the system 100 completes the purchasetransaction and confirms via e-mail the closing of the purchasetransaction with the customers 1340.50.

In the vertical exchange process 1345, the vertical exchange server 1165receives the demand packet 1345.05 and routes the demand packet to aplurality of vertical exchange category fulfillment destinations 1345.10prior to which the vertical exchange server 1165 secures routinginformation from the product network database 700 and vice versa. Basedon the information contained in the demand packet and the aggregatedindications of interest obtained through the demand packet database 400,one or more vertical exchange category fulfillment destinations announcethe offers which includes the pricing 1345.15. The offers are enteredinto a product pricing database 500, and the pricing information ise-mailed to participating customers for reconfirmation 1345.20. In afinite time frame, the system 100 collects reconfirmations from thecustomers that had placed an indication of interest 1345.25, and thisinformation is provided for in the demand packet database 400 and thecustomer sales database 600. It should be noted that one customer may,for one previously entered indication of interest, submit multiplereconfirmations to one or more of the offers received from the system100. Upon transmitting the reconfirmations to all the vertical exchangecategory fulfillment destinations that had made an offer based on thedemand packet, the pricing is confirmed by the system 100, and followingthat, the system 100 negotiates the best price with one or more verticalexchange category fulfillment destinations. This set of final offers iscompared against offers received from the supplier process 1335, theauction process 1340, and the horizontal marketplace process 1350 todetermine the final best price offer 1345.30 which, if accepted by thesystem 100, will prompt the customers for entering credit information1345.35 and, if required, 1345.40 connect the customers to a creditprocessor 940 for credit solutions. As shown in step 1345.45, the systemcollects final shipping information and payment from the customer andstores it into the customer sales database 600. After shipping andpayment information acquisition, the system 100 completes the purchasetransaction and confirms via e-mail the closing of the purchasetransaction with the customers 1345.50.

In the horizontal marketplace process 1350, the horizontal marketplaceserver 1170 receives the demand packet 1350.05 and routes the demandpacket to a plurality of horizontal marketplace category fulfillmentdestinations 1350.10 prior to which the horizontal marketplace server1170 secures routing information from the product network database 700and vice versa. Based on the information contained in the demand packetand the aggregated indications of interest obtained through the demandpacket database 400, one or more horizontal marketplace categoryfulfillment destinations announce the offers which includes the pricing1350.15. The offers are entered into a product pricing database 500, andthe pricing information is e-mailed to participating customers forreconfirmation 1350.20. In a finite time frame, the system 100 collectsreconfirmations from the customers that had placed an indication ofinterest 1350.25, and this information is provided for in the demandpacket database 400 and the customer sales database 600. It should benoted that one customer may, for one previously entered indication ofinterest, submit multiple reconfirmations to one or more of the offersreceived from the system 100. Upon transmitting the reconfirmations toall the horizontal marketplace category fulfillment destinations thathad made an offer based on the demand packet, the pricing is confirmedby the system 100, and, following that, the system 100 negotiates thebest price with one or more horizontal marketplace category fulfillmentdestinations. This set of final offers are compared against offersreceived from the supplier process 1335, the auction process 1340, andthe vertical exchange process 1350 to determine the final best priceoffer 1350.30 which, if accepted by the system 100, will prompt thecustomers for entering credit information 1350.35 and, if required,1350.40 connect the customers to a credit processor 940 for creditsolutions. As shown in step 1350.45, the system collects final shippinginformation and payment from the customer and stores it into thecustomer sales database 600. After shipping and payment informationacquisition, the system 100 completes the purchase transaction andconfirms via e-mail the closing of the purchase transaction with thecustomers 1350.50.

The customer history factor can be determined in a number of ways. Aspreviously described, a customer's actual buying history may be used fordetermining the customer history factor. As an example, if a customersubmits an indication of interest indicating that he or she willpurchase a product, but actually purchases the product 20% of the time,that person's actual buying history (i.e., customer history factor inone embodiment) is 20%. However, such a simplistic model for determininga customer history factor can be expanded to include an unlimited numberof variables or parameters and calculated using a variety ofmathematical functions and statistical models.

The customer related variables (CRV) may be used in determining acustomer history factor:

-   -   Rating variables: rating variables may include customer feedback        score, customer rating, customer ranking, customer score,        customer feedback rating, and so on. Feedback, such as feedback        ratings, may be used to determine each member's feedback score.        A positive rating may add a value, such as +1, to the customer's        score, a negative rating may decrease a value, such as −1, from        the customer's score, and a neutral rating may have no impact.        The higher the feedback score, the more positive ratings the        customer has received from members. In one embodiment, a member        can increase or decrease another member's score by only ±1 no        matter how many transactions they share.    -   Customer transaction variables: customer transaction variables        may include most recent purchases, highest monetary        transactions, average monetary transactions, buy rate, sell        rate, return rate, indication rate, indication-to-buy rate,        transaction frequency, transaction initiation rate, transaction        close rate, and so on.    -   Demographic variables: demographic variables may include age,        gender, race, education, occupation, income, religion, marital        status, family size, number of children, home ownership status,        socio-economic status, and so on.    -   Geographic variables: geographic variables may include various        classifications of geographic areas. For example, the        classifications of geographic areas may include zip code, state,        country, region, climate, population, and other geographical        census data. In one embodiment, this information can come from        national census data. Alternatively, maps, mapping databases,        and other databases as understood in the art may be utilized to        determine the geographic variables. A value may be assigned to        the geographic variables depending on past, current, or future        events affecting the location that a customer lives. For        example, if a location is affected by a natural disaster, such        as a hurricane or flood, the likelihood that the customer will        purchase a product after submitting an indication of interest        may be lower or higher depending on the particular product.    -   Psychographic variables: psychographic variables may include        life style, personality, values, attitudes, and so on. These        variables may be useful in predicting whether a customer will        purchase a product after submitting an indication of interest at        a later date. For example, if a customer's life style includes        business travel, then the customer history factor may be        decreased because there is a potential that the customer will be        traveling when the product begins to sell and the customer will        be unable to purchase the product or forget about the product.    -   Behavioral variables: behavioral variables may include product        usage rate, brand loyalty, benefit sought, decision making        units, ready-to-buy stage, consistent high-end product        purchaser, and so on. A value may be assigned to the behavioral        variables depending on a number of factors. For example, if a        customer routinely purchases high-end products, then the        customer may have a higher score for the high-end product        purchaser variable than someone who does not routinely purchase        high-end products.

Each of the customer related variables used for determining a customerhistory factor may be assigned a value. The values of the variables maybe assigned numeric or alphanumeric values. The variables may beassigned values manually, semi-automatically, or automatically based ona variety of factors. The customer related variables may be used inmathematical functions in computing a customer history factor.

In addition to customer related variables, economic related variables(ERV) may be utilized in accordance with the principles of the presentinvention. Economic related variables may be related to macroeconomic ormicroeconomic factors. For example, macroeconomic variables may includehousehold debt service burden, unemployment, consumer confidence index,producer price index, productivity report, retail sales index, durablegoods orders, employment cost index, personal bankruptcy filings,inflation rate, GDP growth rate, S&P 500 stock market index, and so on.Microeconomic variables may be related to supply and demand related asto individual consumers and businesses in a local region, for example.Microeconomic variables may include supply of current certain products,current demand of certain products, local economy growth rate, consumerjob status, consumer disposable income, and so forth. Applyingmicroeconomic theory, if a particular region of the country is predictedto have a hurricane, certain products may be more important than others,such as flashlights, wood, and water. If a consumer has indicated thathe or she wants to purchase a bedroom set, a value of a variable relatedto the purchase on a microeconomic level may be lowered.

FIG. 14 is a block diagram of an exemplary system 1400 for determining acustomer history factor from various input variables or parameters. Theinput parameters may be stored in one or more databases stored on astorage system (e.g., hard drive of a server). In one embodiment, theparameters may include rating parameters 1402, transaction parameters1404, demographic parameters 1406, geographic parameters 1408,psychographic parameters 1410, and behavioral parameters 1412. Otherand/or different parameters may be utilized in accordance with theprinciples of the present invention. One or more estimation engine(s)1414 may be utilized to determine a customer history factor 1416 basedon one or more parameters 1402-1412. The estimation engine(s) 1414 maybe simple algebraic formulas (e.g., multiplication and addition) or moreextensive logic and/or formulaic approaches, as described hereinbelow.

A customer history factor may be computed in an unlimited number of waysusing the consumer related variables and economic related variables.Some mathematical computations and modeling approaches are providedbelow. It should be understood that these computations and approachesare exemplary and that other computations and approaches may be used tocompute the customer history factor in accordance with the principles ofthe present invention. Furthermore, the customer related variables andeconomic related variables may be used in the computations and models inany combination that is helpful in determining the customer historyfactor to provide a more accurate estimate of how many units of aproduct to produce based on the indications of interest received from anew product offering. Below are exemplary mathematical models andformulas that may be used to compute the customer history factor usingthe consumer and/or economic related variables:

Linear Approach:

The linear models may be structured in the form of a cumulative modelusing customer and/or economic related variables or selective datamodels. Industry selective data models, such as recency, frequency,monetary (RFM) models and chi-squared automatic interaction detection(CHAID) analysis may be used wherever appropriate. The CHAID analysiscan incorporate recency, frequency and monetary variables, but can alsoexamine other variables to increase predictive power. One embodiment maycompute a customer history (CHF) as:

CHF %=CRV %*ERV %

where CRV %=Σ{CRV(1) . . . CRV(n)}/n

-   -   or

CRV %=Σ{CRV(1)/x . . . CRV(n)/z}

ERV %=Σ{ERV(1) . . . ERV(n)}/n

-   -   or

ERV %=Σ{ERV(1)/x . . . ERV(n)/z}

Predictive neural network modeling is a very powerful predictivemodeling technique. It is derived from nerve systems (e.g., humanbrains). The heart of the technique is a neural net (or network forshort). A typical network includes layers of nodes and links betweenneighboring layers' nodes. The first layer is an input layer. Nodes ofan input layer represent induction fields or values of nominal inductionfields. The last layer is an output layer. Nodes of the output layerrepresent prediction values (or class names), i.e., values of a targetfield. The rest of layers are called hidden layers (or middle orinternal layers). There is typically a single hidden layer, but theremay be zero or more hidden layers. For example, the figure shown at theleft-hand side contains a network that determines credit risk levelsbased on gender, age and salary. It includes an input layer of 15 nodes,one hidden layer of 15 nodes and an output layer of 3 nodes.

As understood in the art of neural networks, each link is assigned witha different weight. The weights provide for predictions from the neuralnetwork model, as understood in the art. As shown in FIG. 15, inductionfields, in this case customer related variables and economic relatedvariables, may be presented to the nodes of input layer. The values arepropagated through the neural network to the output layer. In thisprocess, the input values are multiplied with weights, summed, andapplied to a non-linear function. The weights are set such that forgiven inputs, values of output layer reflect predictions, i.e., largevalues (e.g. 0.9) for positive predictions and small values (e.g., 0.1)for negative predictions. Output values are typically in the range of 0and 1. For example, the network of FIG. 15 may output 0.6 for the“certain buyer” output node, 0.2 for the “likely buyer” output node,which predicts as a probable purchaser, and 0.2 for the “unlikely buyer”output node, which predicts as a non-purchaser. It is noted thatcombined output may not be equal to 1. Neural networks are “trained” toproduce certain responses or predictions by an iterative process, andthe weights applied to each input are adjusted to optimize a desiredoutput.

Binary categorical input data for neural networks can be handled byusing 0/1 (off/on) inputs, but categorical variables with multipleclasses (for example, marital status or the state in which a personresides) are awkward to handle. Classifying a result into multiplecategories usually is done by setting arbitrary value thresholds fordiscriminating one category from another. It would be difficult todevise a neural network to classify the location of residence into the50 U.S. states. Classification trees, on the other hand, handle thistype of problem naturally. Neural networks, unfortunately, do notpresent an model that is readily understandable as compared to adecision tree, which is easy to identify initial variables that dividethe data into two categories and then other variables split theresulting child groups.

While a neural network is one potential predictive model that may beutilized to predict whether a potential purchaser of a product whosubmits an indication of interest, it should be understood that otherpredictive and non-predictive logical and mathematical models asunderstood in the art may be utilized to determine whether a potentialpurchaser who submits an indication of interest will ultimately purchasea product. For example, decision trees, stochastic gradient boosting,linear regression and non-linear regression may be utilized. Each ofthese models may enable the various consumer and economic relatedvariables to be processed in making a determination. The result of thedetermination may be a percentage that can be used to determine if orhow many products should be produced for a single potential purchaser ora group of potential purchasers. For example, if a potential purchasersubmits an indication of interest indicating that he or she (or abusiness) is interested in purchasing 100 items of a product and thepredictive model predicts, based on consumer and economic relatedvariables associated with the potential purchaser, that the likelihoodof that potential purchaser is 25%, then the manufacturer can determinethat 25 of the 100 products should be produced for that person, therebyproducing a more accurate demand or supply to minimizing production anddemand overrun.

The previous description is of example embodiments for implementing theprinciples of the present invention, and the scope of the inventionshould not necessarily be limited by this description. The scope of thepresent invention is instead defined by the following claims.

1. A method for determining a price for a product, said methodcomprising: calculating an aggregate customer history factor byaggregating customer history factors of potential purchasers in a buyinggroup, the customer history factors including at least one of thefollowing customer related parameters: customer rating parameter,customer transaction parameter, customer demographics parameter,customer geo graphics parameter, customer psychographic parameter, andcustomer behavioral parameter; calculating a cumulative demand for aproduct as a function of (i) expected purchase quantities of the productindicated by the potential purchasers in the buying group and (ii) theaggregate customer history factor; and setting a price of the product asa function of the cumulative demand for the buying group.